Field of the Invention
The present invention relates to the field of computer aided software engineering and more particularly to build-auditing in a software configuration management tool.
Description of the Related Art
When building computer software, change happens often. Due to the oft-occurring changes in the software development process, software developers have gravitated towards the use of software configuration management tools. Software configuration management refers to the set of activities that are designed to control change by identifying the work product in a software development cycle which is most likely to change, establishing relationships among the identified work product, defining mechanisms for managing different versions of the identified work product, controlling changes that are imposed upon the work product, and auditing and reporting the changes.
A software configuration management system can provide its users both with the ability to record every detail of components used in a software build, and also with the ability to completely recreate the build environment. This requires the software configuration management system to generate a completely accurate software bill-of-materials for a software build. Additionally, the software configuration management system must be able to free the user from the need to manually maintain and declare most build dependencies in order to improve build accuracy and development productivity.
To meet the foregoing characteristics of a software configuration management system, conventional software configuration management systems often perform file-system level auditing. File-system level auditing allows the software configuration management system to capture and record a complete set of configuration information for every software build. File-system level auditing heretofore represents the only known way of supporting complete rebuildability and maintainability. The resulting configuration records can answer critical questions such as, “Has the corrected version of the source code of a particular module been incorporated into the new release?”, “What has changed in between releases?” and, “Which version of the compiler built the source code for a particular module?”.
The build-auditing feature of at least one conventional software configuration management system provides build avoidance during a build of a software product. Build-avoidance refers to the ability to avoid a complete build of a software product where individual modules do not require re-compilation and where the objects of a prior build can be re-used in subsequent build operations. Build-avoidance generally operates by tracking the results of earlier builds through the observation of file-reads. Through observing file-reads, it can be determined whether the results of an earlier build can be reused. In doing this, the build-audit process can account both for changes in source dependencies and also in prior updates to targets in a build referred to as build dependencies.
Build-avoidance technologies at their core account for traditional compilers for third generation languages. In a traditional setting, individual source code modules can be compiled to produce corresponding compiled objects which in turn can be linked and built into a target application. Generally, traditional compiler-linker-builders do not perform dependency checking during the build phase. At best, configuration files for a module can be consulted to ensure that a dependency has been declared albeit the ultimate presence of the dependency cannot be assured. Thus, the build-audit process of software configuration management tools can perform dependency checking on behalf of the compiler-linker-builder.
Unlike traditional third-generation languages, modern programming languages such as the Java programming language provide a traditional compilation process to produce an interpretable target. In the Java programming environment, dependency checking occurs as a matter of course during the build phase. Hence, the dependency checking functionality of an audit-build feature at best can be viewed as redundant and at worst can conflict with the operation of the Java compiler. To wit, the audit-build feature of a conventional software configuration management tool often will rebuild targets which are current and could be safely reused. This, in turn, can result in the inefficient building of Java components.